Skip to content

exec: forward signals to the exec session's process group - #29525

Open
sahilnyk wants to merge 1 commit into
podman-container-tools:mainfrom
sahilnyk:exec-sigproxy-pgid
Open

exec: forward signals to the exec session's process group#29525
sahilnyk wants to merge 1 commit into
podman-container-tools:mainfrom
sahilnyk:exec-sigproxy-pgid

Conversation

@sahilnyk

Copy link
Copy Markdown
Contributor

Fixes: #19486

Killing podman exec left the command it started running inside the container, because the signal was never passed on.

It now signals the process group of the exec'd command. The kernel already puts that command and its children in one group, so there is no process tree to walk.

podman exec --no-session had the same bug and is fixed too.

Tested on runc and crun, rootless and rootful. The new case in 032-sig-proxy.bats fails without this change.

Checklist

  • I have read and understood our contributing guidelines and will not have more than two open PRs as a new contributor.
  • PR description, commit message, and GitHub comments are human-written, per LLM Policy
  • Certify you wrote the patch or otherwise have the right to pass it on as an open-source patch by signing all commits (git commit -s). The author email must match the sign-off email address. See CONTRIBUTING.md.
  • Referenced issues using Fixes: #00000 in commit message (if applicable)
  • Tests have been added/updated (or no tests are needed)
  • Documentation has been updated (or no documentation changes are needed)
  • All commits pass make validatepr (format/lint checks)
  • Release note entered in the section below (or None if no user-facing changes)

Does this PR introduce a user-facing change?

Fixed a bug where killing `podman exec` would leave the command it started running inside the container.

@sahilnyk
sahilnyk force-pushed the exec-sigproxy-pgid branch from 1147aab to 2ae8cf4 Compare August 14, 2026 18:43

@Honny1 Honny1 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM. I have small nits.


logrus.Debugf("Enabling signal proxying to exec session")

go func() {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The goroutine started by ProxyExecSignals runs forever if no signal is ever sent. In the happy-path case, most exec sessions exit normally. This is fine for a CLI tool that's about to exit.

fi
done

kill -TERM $kidpid

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe wait after sending signal?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added it.

@sahilnyk
sahilnyk force-pushed the exec-sigproxy-pgid branch 2 times, most recently from 2ae8cf4 to 3f87e73 Compare August 17, 2026 20:08
@sahilnyk
sahilnyk requested a review from Honny1 August 17, 2026 20:09

@Honny1 Honny1 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

PTAL @podman-container-tools/podman-maintainers @podman-container-tools/podman-reviewers

@Luap99 Luap99 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using a PID like that is unsafe, the pid can be reused and the goroutine is never cancelled so it might send the wrong signal to the wrong process after the main exec session exited.

While this kind of problem exists in many places throughout the codebase podman exec was already converted to using pidfds where possible. So this really must use the the getExecSessionPID and pidhandle.NewPIDHandleFromString logic to verify the pid is really want we want to send signals to.

I think design wise we should not own/act on pids outside of libpod like that. It really should have a libpod function (c *Container) ExecKill(session string, signal unit) which correctly locks the container, syncs the db state and then checks if the session still exists and only then uses the pidfd data to kill it.


then I am not sure we want different behaviours for local vs remote, I understand just doing local is easy but I think ignoring the remote client is a mistake and I rather see us adding a proper REST API to send the signal as well there to have this all in one go.

Comment thread test/system/032-sig-proxy.bats Outdated
@test "podman sigproxy test: exec" {
skip_if_remote "exec sig-proxy is not implemented for podman-remote"

run_podman run -d --name c_exec $IMAGE top

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know existing tests here also hardcode the names but please create a variable for the name cname=c-exec-$(safename), the safename is important to ensure unique per tests names. These tests could be parallelised in the future

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, using cname=c-exec-$(safename) now. Carrying this over to the new PR.

Comment thread test/system/032-sig-proxy.bats Outdated
done

kill -TERM $kidpid
wait $kidpid || true

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please check the exit code of podman exec, it is important to tests that we exit with the right status number for a sigterm, and not silently treat it as success

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added the check. Will bring this over to the new PR too.

@sahilnyk

Copy link
Copy Markdown
Contributor Author

@Luap99 I'll close this PR and open a new one addressing the design you described.

For the remote client, should I open a separate PR to add the REST API for sending the signal, or did you have something else in mind?

@sahilnyk sahilnyk closed this Aug 18, 2026
@Luap99

Luap99 commented Aug 18, 2026

Copy link
Copy Markdown
Member

For the remote client, should I open a separate PR to add the REST API for sending the signal, or did you have something else in mind?

you can do that all in one PR.

In general if changes are request just amened the commit and force push the the same branch. creating new PRs breaks the review workflow for us as we will be unable to follow the changes properly

@sahilnyk

Copy link
Copy Markdown
Contributor Author

you can do that all in one PR.

Noted.

In general if changes are request just amened the commit and force push the the same branch. creating new PRs breaks the review workflow for us as we will be unable to follow the changes properly

Reopening this now, will push the latest design shortly.

@sahilnyk sahilnyk reopened this Aug 18, 2026
@packit-as-a-service

Copy link
Copy Markdown

[NON-BLOCKING] Packit jobs failed. @podman-container-tools/packit-jobs please check. Everyone else, feel free to ignore.

Fixes: podman-container-tools#19486
Signed-off-by: Sahil Nayak <contactsahilpnayak@gmail.com>
@sahilnyk
sahilnyk force-pushed the exec-sigproxy-pgid branch from 3f87e73 to c69e51f Compare August 18, 2026 17:29
@github-actions github-actions Bot added the kind/api-change Change to remote API; merits scrutiny label Aug 18, 2026
@sahilnyk
sahilnyk requested a review from Luap99 August 18, 2026 19:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/api-change Change to remote API; merits scrutiny

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Processes started by podman exec may continue to run after podman exec terminates

3 participants